1. Field of the Invention
The present invention relates to transferring data across a computer network, and more particularly, to transferring video image data from a computer running a server process through a computer network to multiple computers running a client process on an independent basis.
2. Art Background
With the advent of computer and video technologies, it is more and more common to integrate video images into a computer system, such as a workstation or a desktop personal computer, for uses in desktop publishing and multimedia application. Such a system typically consists of a computer with a high performance central processing unit (CPU), a high resolution display system, a video processor, high capacity memory and a video digitizer. The captured video image source may come from a video digitizer, a video frame grabber, or a video encoder/decoder. In a low end video application, a digitizer allows a user to import images from a video camera or VCR, and display or save the images on a computer. A limitation of the digitizer entry is that it usually requires several seconds to capture an image, which makes working with moving subjects, or continuous images, impracticable, In a higher end of technology, a video frame grabber allows a user to capture a single video frame in about 1/30 of a second thus providing much higher bandwidth in video capturing. The captured video frame is converted into digital format suitable for the computer's processor. With the proliferation of computer network systems, it becomes quite common and desirable for individual computers to transfer and receive video images across a network.
An example of a video acquisition device is the VideoPix.TM. card, manufactured by Sun Microsystems, Inc., Mountain View, Calif., which allows users to capture, manipulate, store, and share images. Particularly, when a video digitizer card is connected to a SPARCstation.TM. system, a user can easily capture 8- or 24-bit color or grayscale images and integrate the images into applications such as desktop publishing or multimedia electronic mail.
In an environment of networked computers and peripherals, it is common to pool peripherals, such as I/O devices, printers and offline memory storage for use by each networked computer. In such case, the peripheral called on is referred to as a server and the calling computer is referred to as the client. Also, it is common for a computer to act as a server for other clients when data in the server needs to be accessed by the clients. In computer network parlance, a "server" is a piece of software and/or hardware through which network services are implemented. A "network service" is a collection of one of more remote programs. Usually, a remote program implements one or more remote procedures; the procedures, their parameters, and results are documented in the specific program's protocol specification. In order to access services through the network, network clients issue remote procedure calls (RPC) to initiate the services. A server may support more than one version of a remote program in order to be forward compatible with changing protocols. For example, a network file service may be composed of two programs. One program may deal with high-level applications such as file system access control and locking. The other may deal with low-level file I/O and have procedures such as "read" and "write." A client of the network file service would call the procedures associated with the two programs of the service on behalf of a user on the client computer.
The remote procedure call (RPC) model used by the client to access the server across the network is similar to the local procedure call model. In the local procedure call model, the client caller places arguments to a procedure in some well-specified location (such as a result register). The client then transfers control to the procedure, and eventually gains back control. At that point, the results of the procedure are extracted from the well-specified location, and the caller continues execution. Referring to FIG. 1, the RPC is similar in that one thread of control logically winds through two processes--one is the callers process, the other is the servers process. That is, the caller process sends a call message to the server process and waits for a reply message. The call message contains the procedure's results, among other things. Once the reply message is received, the results of the procedure are extracted, and the client callers own operation is resumed. On the server side, a process is dormant awaiting the arrival of a call message. When one arrives, the server process extracts the procedure's parameters, executes the procedure requested, sends a reply message, including the results of executing the procedure. Note that in this illustrative RPC model, only one of the processes is active at any given time. However, the RPC protocol makes no restrictions on the concurrency model implemented, and others are possible. For example, an implementation may choose to have RPC calls be asynchronous so that the client may perform useful work while waiting for the reply from the server. Another possibility is to have the server create a task to process an incoming request, so that the server can be free to receive other requests. For more discussion on RPC's, see, for example, Network Programming, available from Sun Microsystems, Inc., Mountain View, Calif.
When the server needs to transfer large quantities of continuous data to clients across a computer network, as in the case of broadcasting video image data from the server to clients across the network, the command/response-oriented RPC has its limitations. First of all, digital video data is grabbed from the video data source and continuously transferred across the network to any computer accessing the server, as opposed to data in discrete data files transferred by RPC's. In a network environment, it is also desirable to have optimization processing to achieve efficiency--an area in which the RPC is deficient. The point-to-point communication created by the RPC cannot not allow sharing of network resources among the multiple clients across the network. For example, if another client makes the same request as the previous client, e.g. requesting the same frame of video data by the same format, separate RPCs cannot provide for caching the already formatted data to save processing time. Further, the traditional RPC model cannot support multiple clients each communicating with the server on an independent basis, which enables each client to receive data in its desired format irrespective of other clients' desired formats.
The present invention provides for a network video server for transferring video image data across a computer network to a plurality of clients, where each client can communicate with the server independently, and efficiently. As described, the present invention also achieves optimization by allowing network resources to be shared concurrently among multiple clients.